home *** CD-ROM | disk | FTP | other *** search
/ Aminet 33 / Aminet 33 - October 1999.iso / Aminet / docs / misc / amigapl.9811.lzh / amigapl.9811 / text1364.txt < prev    next >
Encoding:
Text File  |  1998-12-01  |  4.2 KB  |  144 lines
  1. Czo³em,
  2.  
  3.  
  4. Nie by³o mnie przez dwa dni, a kiedy wróci³em moja skrzynka pocztowa by³a
  5. zawalona spekulacjami na temat testowej procedury Darka ¦mietany. Poniewa¿
  6. wyra¿ane opinie by³y dosyæ skrajne i g³ównie koncentrowa³y siê na
  7. przyalignowaniu (b±d¼ nie) struktur, na których operuje move16 do granicy
  8. 16-tu bajtów, przyjrzyjmy siê wspólnie co siê tam w³a¶ciwie dzieje:
  9.  
  10.  
  11. TEST: 
  12.          MOVE.L   BUFORF,D0
  13.          ADD.L #$8,D0
  14.          AND.L #$FFFFFFF8,D0
  15.          MOVE.L   D0,BUFORFM
  16.  
  17. Domy¶laæ siê nale¿y, ¿e BUFORF to arbitralnie zaallokowany blok w pamiêci
  18. FAST. Powy¿sze instrukcje maj± wyznaczyæ pierwszy bajt przyalignowany do
  19. 8-miu. Robi± to, acz dosyæ nieudolnie, poniewa¿ jako parametr instrukcji
  20. ADD wystarczy³aby siódemka -- na okoliczno¶æ gdyby okaza³o siê, i¿ blok
  21. akurat rozpoczyna³ siê od granicy o¶miu bajtów. Jest to sprawa dosyæ
  22. elementarna, ale mo¿e autorowi przy¶wieca³y jakie¶ wy¿sze wzglêdy, trudne
  23. do ustalenia na podstawie tego kawa³ka ¼ród³a.
  24.  
  25. W ka¿dym razie, adres przyalignowanego do 8-miu obszaru pamiêci zostaje
  26. odnotowany w zmiennej BUFORFM.
  27.  
  28.          MOVE.L   BUFORC,D0
  29.          ADD.L #$10,D0
  30.          AND.L #$FFFFFFF0,D0
  31.          MOVE.L   D0,BUFORCM
  32.  
  33. To samo co powy¿ej (zamiast $10 wystarczy³oby $0F), ale tym razem sprawa
  34. dotyczy bufora w pamiêci CHIP, a alignowanie odbywa siê do granicy 16-tu
  35. bajtów. W BUFORCM l±duje adres pierwszego bajtu tak przyalignowanego
  36. obszaru.
  37.  
  38.          MOVE.L   #$AAAAAAAA,D0
  39.          MOVE.L   #$7F,D1
  40.          MOVE.L   BUFORFM,A0
  41. SKOK1:   MOVE.L   D0,(A0)+
  42.          DBRA  D1,SKOK1
  43.  
  44. Pêtelka, która wype³nia pierwszych 512 bajtów bufora (mo¿na zak³adaæ, ¿e to
  45. jego ca³kowita wielko¶æ) w fa¶cie warto¶ci± $AA.
  46.  
  47.          MOVE.L   #800,D4
  48.  
  49. Instrukcja bez znaczenia dla dalszego przebiegu procedury. Wzmaga wra¿enie,
  50. ¿e "test" jest naprêdce wyciachanym fragmentem wiêkszej ca³o¶ci.
  51.  
  52. SKOK5:   MOVE.L   BUFORFM,A1
  53.          MOVE.L   BUFORCM,A0
  54.  
  55. Ustawiamy wska¼niki na pocz±tki przyalignowanych (odpowiednio do 8-miu i
  56. 16-tu) buforów.
  57.  
  58.          MOVEQ #14,D0
  59.  
  60. Ilo¶æ obrotów pêtli -- 15.
  61.  
  62.          MOVE.L   (A1)+,(A0)
  63.          MOVE.L   (A1)+,(A0)
  64.  
  65. Dwa "puste" kopiowania. Zwiêkszaj± wska¼nik w fa¶cie o osiem, tym samym
  66. wyrównuj±c go do granicy 16-bajtów, prawda?
  67.  
  68. Niezupe³nie.
  69.  
  70. Ju¿ pierwotne wyrównanie do o¶miu mog³o spowodowaæ, ¿e adres zosta³
  71. wyrównany równie¿ do szesnastu: we¼my dowoln± liczbê i zaokr±glijmy j± w
  72. górê do wielokrotno¶ci ósemki -- w po³owie przypadków oka¿e siê, ¿e wynik
  73. jest równie¿ wielokrotno¶ci± szesnastki. Je¶li teraz dodamy osiem, oka¿e
  74. siê, ¿e dziêki tej operacji wywrównanie do szesnastu w³a¶nie stracili¶my. W
  75. po³owie przypadków.
  76.  
  77.  
  78.          MOVE16   (A1)+,(A0)+
  79.  
  80. Przerzucamy pierwsze szesna¶cie bajtów...
  81.  
  82. SKOK2:   MOVE16   (A1)+,(A0)+
  83.          MOVE16   (A1)+,(A0)+
  84.          DBRA D0,SKOK2
  85.  
  86. ... i nastêpnych 2 * 16 * 15 = 480. Kopiowanie odbywa siê z FAST-u do
  87. CHIP-u, przy czym zwiêkszenie adresu ¼ród³owego (dwa pierwsze MOVE)
  88. powoduje, i¿ bufory s± przesuniête wzglêdem siebie o osiem bajtów...
  89.  
  90.          MOVE.L   (A1)+,(A0)
  91.          MOVE.L   (A1)+,(A0)
  92.  
  93. ...o których skopiowanie troszcz± siê te dwie instrukcje. Ogólnie A1
  94. inkrementowano tyle razy, ¿eby odczytaæ ca³y bufor (2 * 4 + 16 + 480 + 2 *
  95. 4 = 512 bajtów). Czê¶æ zapisów do CHIP-u posz³a natomiast do tych samych
  96. komórek, tak ¿e bufory s± teraz przesuniête wzglêdem siebie i nie ca³y
  97. bufor w CHIP-ie zosta³ zape³niony. Dlaczego akurat tak -- nie mam pojêcia,
  98. zak³adam ¿e w jaki¶ sposób pomaga to wyeksponowaæ problem.
  99.  
  100.  
  101.          MOVE.L   BUFORCM,A0
  102.  
  103. Bierzemy adres pocz±tku bufora w CHIP-ie.
  104.  
  105.          MOVE.L   #$7B,D1
  106.  
  107. Znowu zbêdna instrukcja....
  108.  
  109.          MOVE.L   #$AAAAAAAA,D0
  110. SKOK3:   CMP.L (A0)+,D0
  111.  
  112. Porównujemy pierwsze d³ugie s³owo z bufora z tym, co powinno siê w nim
  113. znajdowaæ.
  114.  
  115.          BNE.B ERROR
  116.  
  117. Nie zgadza siê? Pech...
  118.  
  119.          MOVEQ #1,D0
  120.          RTS
  121.  
  122. Ufff.
  123.  
  124. ERROR:
  125.          MOVEQ #0,D0
  126.          RTS
  127.  
  128. Kasa = Kasa - 330zl.
  129.  
  130.  
  131.  
  132. Moje pytanie do pana Darka: jak to w koñcu jest z tym przyalignowaniem do
  133. 16-tu, hê? Nie mam ani FAST-ATA, ani PPC, ani nawet "test" nie robi u mnie
  134. krzaków, ale chêtnie bym siê dowiedzia³, czy oryginalny ata.device (czy jak
  135. mu tam), alignuje równie mistrzowsko jak procedura testowa.
  136.  
  137. Hej,
  138. Mi³ek
  139. -- 
  140. mailto:thorgal@amiga.com.pl   |  "Man in the Moon and other weird things" -
  141. http://wfmh.org.pl/~thorgal/  |  see it at http://wfmh.org.pl/~thorgal/Moon/
  142.  
  143.  
  144.